IBIS Macromodel Task Group

Meeting date: 09 June 2020

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                            * Jared James
Google:                     * Zhiping Yang
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Todd Bermensolo
                              Stephen Slater
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Bob to send BIRD201.1_draft8 to the ATM email reflector and for submission to
  the Open Forum.
  - Done.
 
- Randy to post BIRD201.1 on the IBIS Open Forum BIRDs web page.
  - Done.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the June 02
meeting.  Walter moved to approve the minutes.  Michael seconded the motion.
There were no objections.

-------------
New Discussion:

Editorial Change to Rx_Clock_Recovery_Mean:
Hansel shared a slide detailing his proposed change.  He noted that he found the
language:

    "... medians of consecutive edge transition times ..."
    
in the Definition of the parameter to be confusing.  He said "transition times"
led him to think of the time it takes to transition from one state to the other.
He proposed changing the text to:

    "... medians of consecutive edge threshold crossing times ..."
    
Similarly, he proposed changing "edge transition times" to "edge threshold
crossing times".

No one expressed opposition to the proposal.  Arpad asked if it would be handled
as an editorial process or required a BIRD.  Bob, Randy, and Radek said that it
should be handled as a BIRD because it is more of a clarification of a technical
point than a pure editorial change.  Hansel took an AR to draft a BIRD.

Supporting PI Simulation in IBIS:
Zhiping noted that he had given a presentation about the topic at the last Open
Forum meeting.  He said people had pointed out that IBIS is primarily focused on
I/O.  He agreed, but said that PI and SI are often closely coupled for I/O, and
PI can affect core and I/O.  He noted that some IBIS keywords, e.g., [ISSO_PU]
and [Composite Current], were designed around PI.  He said that system designers
typically want to include PDN modeling and often resort to ideal power
management IC models.  However, they really want to simulate SSO noise and timing
jitter, and it would be more accurate to have PMIC behavior modeled in the
simulation as well.

Arpad said that many EDA tools are now offering power-aware simulations with the
power delivery network included.  He asked if Zhiping had a vision for the
simulation flow.  He said part of the difficulty was the widely differing
frequency ranges to be simulated for I/O buffers and VRMs.  A related issue was
the on-die and on-board decoupling capacitance question.  At the higher speeds
of I/O buffers, package and even on-die decoupling caps are more important.

Zhiping agreed that most people are interested in the GHz range for I/O.
However, he said that even for a GHz link the jitter spectrum is much lower.
Typically CDR jitter tracking is in the MHz range.  He said that in the past
people typically tried to run SI and PI simulations independently and then
estimate their coupled effects.  But nowadays most accurate simulations need
SI PI cosimulation.  For example, for a SOC DDR bus, you have signal and power
closely coupled in a thick package.  It would be inefficient and or inaccurate
to try to model SI and PI separately.  Jitter is another area where
cosimulation is important.  In a SERDES you have a clock tree, CDR, etc., and
you're worried about power supply induced jitter (PSIJ), so people want to run
the jitter simulation in conjunction with the power simulation.

Arpad asked if Zhiping had any ideas for the type of information we could add to
an IBIS model to help.  He again noted the widely varying timescales and said
that if you're simulating GHz I/O buffers (ps time scales), but you need to run
long enough for a VRM with a feedback loop in the 100kHz range, it will take
forever.  Zhiping said he didn't have an answer or a solution.  He was hoping we
could all agree that PI simulation is an important problem for high speed IC
design.  He noted that the IEEE EMC Society is holding a sandpit event to
collect industry feedback and categorize it into different buckets.  He
suggested, for example, that it might be easy to come up with an IBIS keyword to
add to support DC analysis and describe power dissipation.  For AC or transient
analysis, however, solutions could be more complicated and controversial.  He
was hoping IBIS could help find a way to standardize the necessary information
in much the same way it had for I/O modeling.

Walter asked if, from the point of view of IBIS I/O buffer models, all we needed
to do was add a keyword indicating the number of Coulombs (amount of charge) the
buffer uses for each transition.  With that data, EDA tools could look at the
duty cycle of the I/O signal and other factors and compute the spectral density
of the power consumption and how the voltage rails would vary.  Walter said you
could integrate over a [Composite Current] curve, which contains current vs.
time.  Zhiping said coming up with a single number for Coulombs per transition
would be tricky, since it varies with many factors.  The [Composite Current]
BIRD itself envisioned tables for 3 sets of load conditions.  Walter then said
you could then run a single IBIS simulation given the channel being driven,
and it would determine the Coulombs per cycle consumed.  This was all IBIS would
need to contribute to a low speed PI simulation.

Zhiping said I vs. time provides more information than total charge consumed,
and it's a question of how fast you need the charge delivered through the PDN
that is important.  Walter agreed that would be a more interesting simulation,
but it was outside the domain of IBIS I/O simulation.

Arpad asked for feedback from IC vendors.  Walter noted that every time he'd
worked on this with IC vendors in the past, either using measurement or
sophisticated simulation, they would find a spectral density of the rail voltage
and that would be their power aware simulation.  The IC vendors would do that
simulation, not their customers, and they would use that simulation to compute
jitter parameters to put in their models.

Arpad asked what the main purpose of this would be, modeling the VRM?  Zhiping
said he was thinking of two parts, first how to model the VRM, and second how to
model the sink .  For the sink modeling, you could have I vs. t, or average
power, or peak, and possibly DC and perhaps including noise specifications and
requirements for the power rail.

Arpad suggested we move on to other topics and return to this one next week.
Zhiping asked everyone to feel free to send him questions and feedback via
email.  He noted the upcoming IEEE EMC Society sandpit event and said he'd be
happy to include anyone in those discussions.

BIRD201.1 demo:
As he'd agreed to do at the previous meeting, Walter provided a demo of his
BIRD201 type proof of concept simulation.  His demo was for a DDR5 channel in
which the Tx had a 3-tap FFE and the Rx had a 4-tap DFE, i.e., a typical DDR5
write simulation.

He showed a MATLAB implementation of the flow.  The script took in the step
response(s) (rising, falling or both) of the channel, generated the IR, and
called the Tx and Rx AMI_Init functions repeatedly (calling AMI_Close after
each call to AMI_Init).  It implemented a simple steepest-descent algorithm.
For each step in the optimization, 15 simulations were run: one at the current
tap settings, and one simulation for each of the taps with its value raised by
one, and one simulation for each of the taps with its value lowered by one.
Whichever simulation yielded the best metric was the one chosen for the next
step.  In the DDR5 example it took about 165 iterations to converge and about
five seconds.  In a more complicated 23 tap FFE example it had taken about 1000
iterations, but was still fast enough.

The script computed metrics like eye height, eye width, COM, area, width times
height.  Walter noted that in a true BCI Statistical BIRD201.1 flow, instead of
the logic being in the script (EDA tool), it would reside in the Tx or Rx
AMI_Impulse function.  In a DDR5 write scenario, it would reside in the Tx
AMI_Impulse function, since the controller optimizes the channel on writes.

Walter noted this his script generated COM and eye height at two locations, one
where the maximum eye height occurs, and one at the midpoint of the eye with
respect to the left and right crossings.  He noted that the newly introduced
BIRD205 lets the model determine where the sampling location should be, which
also affects the DFE since it kicks in 0.5*UI later.  It's also why the clock
forwarding BIRD204 was introduced, because when the DQS crosses zero is when you
typically sample the DQ.

Fangyi asked about the COM values displayed by Walter's script, and noted that
COM has its own CTLE, DFE, etc.  Walter agreed, and said that COM essentially
says, "give me an IR, and I have my own DFE, FFE and CTLE", and it doesn't
generate an eye it generates a single histogram at a particular sampling
time.  The COM value is the signal to noise ratio.  Walter said his script
computed the SNR with the signal being the inside height of the eye.  He said
COM typically just assumes you can equalize the channel properly in your 
implementation.  For example, it zeros out the pulse response for as many
taps as you have, and then computes SNR.  It doesn't really care about the
details of any particular implementation, it just assumes the implementation
can handle the equalization correctly.  It's purely a metric of the channel.

- Curtis: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

AR: Hansel to draft a BIRD for his proposed change to the text defining
    Rx_Clock_Recovery_Mean.

-------------
Next meeting: 16 June 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
